Suggestion from my side, since java.time.Instant is a more modern and efficient API for dealing with timestamps, it is advisable to switch to Instant.
This also avoids potential issues with different time zone handling in java.sql.Timestamp.

Also, here DbTimestamp wrapper for truncation can be created as we already did for orchestrator entities. This will ensure that timestamps are always truncated to microseconds, which can be useful if you want to avoid precision issues between application and the database.

Hi Sujit, thanks for your suggestion. I have a question regarding using Instant. The value submitted by the customer will either be null or a String value like "2024-07-18 16:45:05", is it still suitable to use Instant in this case?

My recommendation is switch to Instant as is the best choice due to its modern design, better time zone handling, and higher precision. Handling null and string values can be easily managed with appropriate parsing and conversion logic.

Refactor the upsertFromEntity function: Improve readability and efficiency by avoiding redundant null checks and using more idiomatic Kotlin. We can have something like below,

val hasChanges = compareUtil.hasChanges(upsertData, partnerToUpsert)
val shouldUpdate = when {
       upsertData.currentness == null -> true
       existingPartner?.currentness == null -> true
       else -> upsertData.currentness.isAfter(existingPartner.currentness)
 }

 if (hasChanges && shouldUpdate) {
       changelogRepository.save(ChangelogEntryDb(sharingState.externalId, sharingState.tenantBpnl, changeType, stage))
       copyUtil.copyValues(upsertData, partnerToUpsert)
       businessPartnerRepository.save(partnerToUpsert)
}

Let's not mix the technical problem of messages / versions of the same business partner arriving in a wrong order with the currentness of the business partner. Currentness information has business value to it and must be added anyway sooner or later to the Gate as it is already available in the Pool. It may well be, that the currentness of a business partner needs to be changed, because currentness information was wrong. If the corrected currentness lies before the wrong currentness, this change would not be possible with this code. Let's remove this code here and rather introduce an integer version number at a business partner or a sequence number at the message level in another pull request. This version / sequence number could be optional for those source systems, that handle sequence problems on their own. If it is set, it must be incremented on each change of the business partner / sending of a message. Source systems not having an integer version / sequence number could rely on converting the timestamp to a unix time. This is best practice in other MDM system for decades.